Description
Undo when the editor is not in focus will change editor content, but won't update editor state.

In my tests, this issue only appears on Chrome/Chromium. It doesn't occur on Firefox, Safari, or Edge. However, the #5544 report indicates that it also happens on Edge and Safari, so I didn't limit the patch to Chrome.

Issue
Fixes: #5544

Example

After entering some content, click elsewhere to make the editor lose focus. Then use Ctrl/Cmd+Z to undo. When you start typing again, you'll notice the previously undone content reappears.

After making adjustments.

Context

I tried to get to the root of the problem. If you completely preventDefault the beforeinput event, nothing will be placed in the browser's undo stack, so input events like historyUndo won't be triggered.

As mentioned in the comments, if you completely block the event, we won't be able to handle undo events in beforeinput.

However, because there's a conditional preventDefault in the beforeinput event, some content will still enter the browser's undo stack. For example, typing 123 won't cause the issue, but typing abc will trigger the undo problem when losing focus.

I came up with four solutions to address this issue.

1. Completely prevent the default behavior of the beforeinput event. However, this could be a major disruptive change and might not be suitable for solving this problem.
2. Completely prevent the browser's undo action when losing focus. After researching the issue, I found that to prevent it, we need to listen to the document's onKeyDown event (since the editor loses focus and won't trigger its own onKeyDown event). This might require "excessive" permissions.
3. Sync the editor's state when undoing after losing focus. This solution requires us to actively trigger the editor's undo/redo methods when this action occurs to sync the editor's built-in state.
4. Clear the undo stack for the DOM nodes. But as far as I know, there's no way to do that right now. Maybe a future undo manager(undo manager w3c/editing#209) or API could make it possible.

In the end, I chose option 3. I found that triggering this behavior only fires the oninput event of that node, while the onbeforeinput and onkeydown events don't get triggered. It's quite fascinating.

Also, I tried to prevent the undo action in this input event, but it didn't work. event.preventDefault didn't do the trick here. So, I decided to check whether we should be in edit mode to determine if we should manually call the editor's undo/redo methods. Interestingly, when this action is triggered, we can determine the state by checking the focus.

In this case, I ran a lot of tests to avoid any unexpected undo/redo actions.

1. Triggering an input event without focus is actually a patch for special behavior. When there's focus, this logic won't apply. Also, this event is specific to the DOM node, not triggered globally, so it's related to the state of the node itself.
2. The beforeinput event will call preventDefault for inputTypes of historyUndo and historyRedo, so the input event won't proceed here.
3. The onkeydown event for undo/redo will also call preventDefault, so the input event won't be triggered.
4. I mocked a flag indicating that the beforeinput event is not supported. In this case, all input will be prevented, nothing will enter the browser's undo stack, and the input event won't be triggered.

Checks

• The new code matches the existing patterns and styles.
• The tests pass with yarn test.
• The linter passes with yarn lint. (Fix errors with yarn fix.)
• The relevant examples still work. (Run examples with yarn start.)
• You've added a changeset if changing functionality. (Add one with yarn changeset add.)